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EXPERIENCE  WITH  Q 


IMPLEMENTATION  OF  A 
PROTOTYPE  PROGRAMMING  ENVIRONMENT 

PART  V 


Bruce  J.  MacLennan 
Computer  Science  Department 
Naval  Postgraduate  School 
Monterey.  CA  93943 


Abstract: 

This  is  the  fifth  report  of  a  series  exploring  the  use  of  the  f2  programming  notation  to  prototype  a  pro¬ 
gramming  environment.  This  environment  includes  an  interpreter,  unparser,  syntax  directed  editor, 
command  interpreter,  debugger  and  code  generator,  and  supports  programming  in  a  small  applicative 
language.  The  present  report  presents  a  code  generator  operating  on  abstract  syntax  trees.  The  code 
generation  process  is  implemented  as  an  evaluator  over  a  nonstandard  domain  An  implementation  of 
the  code  generator  is  listed  in  the  appendices. 


1.  Introduction 

Our  goal  in  this  series  of  reports*  MacLen nan85b,  MacLennan85c,  MacLenn an86a,  MacLennan86b  is 
to  explore  in  the  context  of  a  very  simple  language  the  use  of  the  Q  programming  notation  MacLen- 
nan83,  MacLennan85a  to  implement  some  of  the  tools  that  constitute  a  programming  environment 

In  this  report  we  define  a  code  generator  for  abstract  programs.  The  code  generator  will  be  a 
member  of  the  same  family  as  the  interpreter  and  the  un parser.  That  is.  it  will  be  an  evaluator  for 
abstract  programs  defined  on  the  domain  of  code  sequences  First  we  discuss  machine  and  run-time 
structure;  next,  informal  translations;  and  finally  present  the  translation  rules. 


2.  Target  Machine  Structure 

We  will  generate  code  for  a  stack  machine  with  several  special  purpose  registers  ( EP  SP)  and  several 

temporary  registers  (Tl.  T2).  It  has  the  following  instructions: 

Support  for  this  research  was  provided  by  the  Office  of  Naval  Research  under  contract  N0001 4-86- WR-24 092. 
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LDC  k  -  load  constant 


•  ADD,  SUB,  MUL,  DIV,  EQL,  etc.  —  arithmetic 

•  JMP  /,  JMPT  /  —  unconditional  jump,  jump  on  true 

•  LBL  /  —  define  label 

•  SKIP  S  —  skip  down  static  chain 

•  LOD  —  load  contents  of  variable 

•  ENTER,  EXIT  —  block  control 

•  CALL.  RETURN  —  function  control 

•  PUSH  r,  POP  r  —  stack  control 

•  BREAK  —  enter  debugger 

3.  Run- Time  Structure 

We  use  a  conventional  static-chain  implementation  for  statically-scoped  languages.  Note  that  this 
stack-based  activation  record  structure  will  not  support  function- valued  functions,  which  are  supported 
by  the  interpreter.  This  incompatibility  between  the  interpreter  and  code  generator  is  very  serious,  but 
not  addressed  in  the  present  report,  since  it  would  not  affect  the  use  of  Q  as  a  tool  for  writing  the  code 
generator.  Exercise  for  the  reader:  define  a  non-stack-based  activation  record  structure  that  solves  this 
proble  m . 

Consider  the  following  program: 

let  A  =  1 
func  F  X  = 

let  B  =  (X  x  A) 

[let  C  =  3 
(if  (X  >  0) 
then  F  (C  +  (X  -  B)) 
else  0)  ]  ] 
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F  (A  x  2) 


This  diagram  illustrates  the  run-time  data  structures  when  execution  is  within  the  ‘let  B  =  block  on 
the  recursive  invocation  of  F: 


ED  yric\  vyi  j  c 
C  h  y  y\ 


EP 


t  -  h  c. 
h  ^  ^ 


Notice  how  the  static  links  for  both  of  F’s  activation  records  point  to  the  environment  defining  F.  The 
ep/ip  pair  is  the  dynamic  link. 
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4.  Informal  Translation  Rules 


4.1  Constants,  Variables  and  Applications 

For  constants  we  merely  stack  the  constant  value: 

k  =o  LD C  k 

For  variables  we  must  first  scan  down  the  static  chain  to  the  environment  of  definition  of  the  variable 
Then  the  value  of  the  local  variable  from  that  environments  activation  record  can  be  loaded  onto  the 
stack: 

SKIP  6 
v  LOD 

where  S  is  the  static  distance  to  its  activation  record. 

The  code  for  an  application  is  illustrated  by  this  example: 

X 

,Y+  Y  ==>  Y 

ADD 

The  X  and  Y  on  the  right  represent  the  code  corresponding  to  the  X  and  Y  on  the  left.  Thus  we  gen¬ 
erate  code  that  executes  X  and  Y  in  order  and  leaves  their  values  on  the  stack  where  they  can  be 
popped  by  ADD. 

4.2  Conditional  Expression 

Code  for  a  conditional  first  evaluates  the  condition,  leaving  a  Boolean  value  on  the  stack.  A  JMPT 
instruction  can  then  be  used  to  test  this  value,  skipping  the  alternate  and  jumping  to  the  consequent 
when  the  value  is  true. 


(if  B 
then  T 
else  F  ) 


B 

JMPT  r 
F 

JMP  u; 
LBL  r 
T 

L  BL  u > 


Of  course  the  code  for  the  alternate  must  end  with  a  JMP  to  skip  the  consequent. 
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4.3  Blocks 


The  first  step  in  the  code  for  a  block  is  the  evaluation  of  the  bound  value  E  in  the  surrounding  con¬ 
text  Two  macroinstructions,  ENTER  and  EXIT,  surround  the  block  body  B ,  and  handle  the  entry  and 
exit  of  the  block  context: 

E 

I  let  v  =  E  ENTER 

B  ]  “9>  B 

EXIT 

The  ENTER  macroinstruction  must  create  the  block's  activation  record,  incorporating  the  bound  value, 
and  link  the  activation  record  into  the  static  chain  It  is  equivalent  to  the  following  operations: 

PUSH  EP  {SL} 

EP-SP  {set  EP} 

That  is,  we  push  the  old  value  of  the  EP  register  (which  is  a  pointer  to  the  surrounding  context)  onto 
the  stack,  thus  forming  the  static  link  of  the  new  activation  record.  The  value  of  the  bound  value  E  is 
already  on  the  stack,  where  it  will  be  accessible  as  the  local  value  in  the  new  activation  record. 
Transferring  the  contents  of  the  stack  pointer  (SP)  to  the  environment  pointer  (EP)  installs  the  neu, 
activation  record  as  the  active  one. 

The  EXIT  macroinstruction  must  save  the  value  computed  by  the  block  (which  is  on  the  top  of  the 
stack)  while  the  block’s  activation  record  is  deleted.  Its  code  expansion  is  straight-forward 


POP  Tl 

{bloc  k  value } 

POP  EP 

{SL} 

POP  - 

{local} 

PUSH  Tl 

{block  value} 

4.4  Function  Definition 

Consider  a  function  definition  such  as  the  following: 

func  f  n  -  B 
X 


-o- 


This  is  very  much  like  a  let  block,  except  that  execution  of  the  function  body  B  must  be  deferred  until 
the  function  /  is  invoked: 


JMP  (jj 
LBL  <t> 

B 

RETURN 
LBL  u 
LDC  <t> 
ENTER 

X 

EXIT 


{skip  function  body} 

{entry  point} 

{body  of  function} 

{return  to  function} 

{here  to  skip  function  body} 
{stack  entry  point} 

{enter  func.  defn.  block} 
{body  of  func.  defn.  block} 
{exit  func.  defn.  block} 


The  function  body  is  represented  by  the  LBL  <p  (which  is  its  entry  point),  the  code  B.  and  the 
RETURN  macro  instruction  (which  is  discussed  below).  The  JMP  u>  skips  the  function  body,  thus 
deferring  its  execution.  The  LDC  <2  stacks  the  entry  point  address  as  the  local  value  of  the  function 
block,  which  is  then  ENTERed  and  EXITed  in  the  usual  way 


4.5  RETURN  Instruction 

The  RETURN  macroinstruction  has  the  task  of  saving  the  function’s  value  (which  is  on  the  top  of 
the  stack),  restoring  the  callers  environment,  deleting  the  function’s  activation  record,  leaving  the 
function’s  value  on  the  top  of  the  stack,  and  resuming  execution  of  the  caller.  The  code  to  accomplish 
this  is: 


POP  Tl 

{return  value} 

POPEP 

{caller’s  EP} 

POP  T2 

{caller’s  IP} 

POP- 

{SL} 

POP- 

{param} 

PUSH  Tl 

{return  value} 

JMP  T2 

{resume  caller} 
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The  first  POP  saves  the  function’s  value  in  temporary  register  Tl.  The  second  restores  the  callers 


environment  from  the  dynamic  link  (EP/IP  pair).  The  third  saves  the  caller’s  resumption  address  in 
temporary  register  T2.  The  next  two  POPs  delete  the  function’s  activation  record.  The  PUSH  instruc¬ 
tion  puts  the  function’s  value  back  on  the  top  of  the  stack,  and  the  indirect  JMP  through  T2  transfers 
control  back  to  the  caller. 

4.6  Function  Invocation 

The  code  sequence  for  the  function  application  4 /  A'1  is  as  follows: 


/  A'  =- 

X 

SKIP  b 

LOD 

SKIP  6  + 1 

CALL 

where  b  is  static  distance  to  / ’s  environment  of  definition.  The  first  SKIP  moves  to  the  activation 
record  of  the  function  block  so  that  the  LOD  can  access  the  entry  address.  The  second  SKIP,  which 
goes  one  static  link  further,  accesses  the  environment  of  definition  of  the  function.  The  CALL 
macroinstruction  completes  the  invocation  process. 

The  CALL  macroinstruction  has  the  task  of  constructing  an  activation  record  for  the  callee  and 
transferring  control  to  the  callee.  This  is  accomplished  by  the  following  code  expansion: 


POP  Tl 

{get  env .  of  defn. } 

POP  T2 

{get  entry  address} 

PUSH  Tl 

{static  link} 

PUSH  p 

{caller’s  IP} 

PUSH  EP 

{caller's  EP} 

EP-SP-2 

{callee’s  SL} 

JMP  T2 

{enter  function} 

LBL  p 

{return  location} 

On  entry  to  the  CALL  macroinstruction  the  top  of  the  stack  is  the  environment  of  definition  of  the  cal¬ 
lee,  the  second  on  the  stack  is  the  entry  point  address,  and  the  third  on  the  stack  is  the  actual  parame- 
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ter  value: 


env.  of  defn. 


entry  point 


actual 


The  first  two  are  saved  in  registers  Tl  and  T2.  The  actual  parameter  is  left  on  the  stack  to  form  the 
first  component  of  the  callee’s  activation  record.  The  next  component  is  its  static  link  (whose  value 
was  saved  in  register  Tl) .  Then  we  save  the  caller's  IP  (the  resumption  address  p)  and  EP  (which  was 
in  the  EP  register);  together  they  constitute  the  dynamic  link  back  to  the  caller  Finally,  EP— SP— 2 
installs  the  callee’s  activation  record  as  the  active  one,  and  the  indirect  JMP  through  T2  transfers  con¬ 
trol  to  the  function.  The  LBL  p  of  course  defines  the  return  point  in  the  caller.  (Exercise  for  the 
reader:  Why  l  —  2'  in  lEP— SP— 2'?)  The  completed  activation  record  looks  like  this  * 


ep 


IP 


SL 


par  am. 


4.7  Example 

Consider  the  following  simple  program: 

let  K  =  4 
func  fac  n  = 

(if  (n  =  0) 

then  1 

else  (  n  x  fac  ( n  —  1 ) )  ) 
fac  K 


The  following  code  will  be  generated: 
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LDC  4 

local  value  K  -  4 

ENTER 

enter  ‘let  K  =  * 

JMP  L3 

skip  body  of  fac 

LBL  L4 

entry  point  of  fac 

SKIP  0 

access  formal  n 

LOD 

fetch  value  n 

LDC  0 

stack  0 

EQL 

compare,  (n  —  0) 

JMPT  Ll 

if  true,  skip  alternate 

SKIP  0 

access  formal  n 

LOD 

fetch  value  n  (to  multiply) 

SKIP  0 

access  formal  n 

LOD 

fetch  value  n  (to  subtract) 

LDC  1 

stack  1 

SUB 

compute  actual  param  (n  -  1 

SKIP  1 

access  defn  of  fac 

LOD  . 

fetch  entry  point  address 

SKIP  2 

access  fac:s  env,  of  defn. 

CALL 

call  fac  ( n  -  1) 

MUL 

multiply  n  by  result  of  fac 

JMP  L2 

skip  consequent  of  if 

LBL  Ll 

alternate  of  if: 

LDC  1 

stack  1 

LBL  L2 

end  of  if 

RETURN 

return  from  fac 

LBL  L3 

here  to  skip  over  fac 

LDC  L4 

stack  entry  point  of  fac 

ENTER 

enter  ‘fane  fac  =  ’  block 

-9- 


SKIP  1 

access  context  of  K 

LOD 

fetch  value  of  K 

SKIP  0 

access  context  of  fac 

LOD 

stack  entry  point  of  fac 

SKIP  1 

access  env.  of  defn.  of  fac 

CALL 

call  fac  K 

EXIT 

exit  func  fac  =  ’ 

EXIT 

exit  ‘let  K  =  ’ 

Exercise  for  the  reader:  trace  the  execution  of  this  program  showing  all  stack  states. 
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5.  Code  Generation 


5.1  Introduction 

The  code  generator  is  like  Eval  and  Unparse,  except  that  we  change  the  domain  on  which  the 
evaluation  is  done: 

U nparse (  E)  =>  “(3+5)” 

Eval(£,  C)  =>  8 

CodeGen (E,C)  =*>  <  LDC  |3|,  LDC(5j,  ADD> 

Notice  that  the  “value”  computed  by  CodeGen  is  a  list  of  target  machine  instructions. 

5.2  Code  Generation  Relations 

The  relations  required  for  code  generation  are  exact  analogs  of  the  Eval  and  V  alue  relations  in  the 
interpreter: 

•  CodeGen  (E,  C) 

request  code  generation  for  E  in  context  C 

Degree  (CodeGen,  2),  Domain  (expr,  1,  CodeGen),  Domain  (Context.  2.  CodeGen). 

.  Code  (  C.  £,  C) 

U  is  the  code  for  E  in  C 

Function  (Code,  exprXContext,  code-list). 

5.3  Constants 

The  code  for  a  constant  is  simply  the  appropriate  LDC  instruction,  which  we  assume  to  be  generated 
by  the  function  Con: 

*CodeGen  ( £,  C),  Con  (£),  LitVal  (  K,  E) 

=>  Code  (<  Con  |  V]  >  ,  E). 

Note  that  because  the  range  of  Code  is  defined  to  be  a  code  list,  it  is  necessary  to  return  Con  V\  as  a 
one-element  list. 
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5.4  Applications 


We  need  an  additional  relation,  OpCode,  which  is  a  table  giving  the  target  machine  opcode  for  each 
primitive  operator.  This  relation  corresponds  to  the  Meaning  relation  of  the  interpreter  and  the  Tem¬ 
plate  relation  of  the  un parser. 

.  OpCode  (F,  N) 

•  F  is  the  opcode  for  N 

•  Function  (OpCode,  string,  operation). 

The  analysis  rule  for  applications  must  request  the  code  generation  of  the  two  argument  expressions: 

*CodeGen  (F,  C).  Appl  (F),  Left  (A',  E ),  Right  (  F ,  E) 

CodeGen  (X,  C),  CodeGen  (  F,  C). 

The  synthesis  rule  catenates  the  code  sequence  for  the  arguments  with  the  appropriate  arithmetic  opera¬ 
tion  found  in  OpCode: 

Appl  (F),  Op  (TV,  F),  Left  ( AT,  F),  Right  (  F ,  E) , 

*Code  (  F,  Ar,  C),  *Code  (  V,  F,  C),  OpCode  (F,  N) 

=->  Code  (U  *  V  “<F>,  E.  C). 

Note  that  the  opcode  is  made  into  a  one  element  list  so  that  it  can  be  catenated  with  the  code  lists  V 
and  V. 

5.5  Conditionals 

The  analysis  rule  for  conditionals  requests  the  code  generation  of  the  three  parts  of  the  conditional: 

*CodeGen  ( E ,  C),  ConEx  (F),  Cond  (B,  F),  Conseq  (  7\  F),  Alt  ( F,  F) 

==?>  CodeGen  (B,  C),  CodeGen  (  F,  C),  CodeGen  ( F,  C). 

The  synthesis  rule  assembles  these  with  the  appropriate  jump  instructions 
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ConEx  (£),  Cond  ( B ,  E) ,  Conseq  (  T,  E ),  Alt  (7,  E) 

*Code  (17,  E,  (7),  *Code  (  V}  7\  (7),  *Code  (  W ,  7,  (7),  *Avail  (r,  w) 

=?>  Code  ( 

u  * 

<  JMPT  [r]  >  m 

W  ~ 

<  JMP  w],  LBL  [ r  ]  >  * 

V'  A 

<  LBL  uj\  >  ,  E  C). 

The  only  complication  is  that  unique  lables  r  and  w  must  be  generated 
5.6  Block  Structure 

Contexts  will  be  computed  during  code  generation  just  as  they  are  during  evaluation.  However,  a 
name  is  bound  to  its  static  nesting  level  instead  of  its  value  (which  is  not  known  until  runtime). 

Variable  lookup  is  requested  by  the  Access  relation:  its  static  nesting  level  is  returned  in  the  Loca¬ 
tion  relation. 

*  Access  ( Ar,  D ,  E ,  (7) 
access  N  in  D  for  E  in  C 

Function  (Access,  expr  x  Context,  stringxContext). 

•  Location  (  L  .  E.  C) 

L  is  the  location  for  E  in  C 

Function  (Location,  exprx Context,  integer). 

The  rules  governing  the  Access  process  are  exact  analogs  of  the  Lookup  rules  in  the  interpreter. 
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*Access  (TV ,  D,  E ,  C),  Binds  (D,  TV,  L), 

=>  Location  (L,  E,  C ) 

else  ^Access  (TV,  D,  C),  Nonlocal  ( D  '  D) 

=>  Access  (TV,  D\  E,  C) 

else  ^Access  (Ar,  D ,  C) 

=>  Break  (“Undefined:  ”  "TV,  £,  C). 

5.7  Variables 

The  analysis  rule  for  variables  simply  request  that  Access  determine  the  variable’s  location: 

*CodeGen  (£7,  C),  Var  (E),  Ident  (TV,  E) 

=>  Access  (TV,  C,  E,  C). 

The  synthesis  rule  waits  for  the  static  distance  to  be  returned  in  Location,  and  incorporates  it  into  the 
appropriate  SKIP  instruction: 

Var  (£),  *Location  (L,  E,  C),  Binds  (C,  —  ,  K ),  — Rator  (E,  —  ) 

=*>  Code  (<  SKIP  \K-L],  LOD>  ,  E ,  C). 

The  condition  ‘-Rator  ( E ,  -  )’  is  a  bit  of  a  kluge:  it  prevent  the  activation  of  this  rule  on  variables  that 
happen  to  be  the  operator  of  a  function  application,  which  must  be  handled  differently.  A  runtime 
structure  that  supported  function-valued  functions  (and  variables)  would  eliminate  the  need  for  this 
kluge:  exercise  for  the  reader. 

5.8  Blocks 

The  analysis  rule  for  blocks  requests  code  generation  for  the  bound  value  and  the  block’s  body. 

*CodeGen  (£*,  C),  Block  (£),  BndVar  (TV,  E ),  BndVal  (X,  E),  Body  ( B ,  E ), 

Binds  (C,  -  ,  X),  *Avail  (D) 

==>  Context  (D).  Binds  (D  A,  K  + 1),  Nonlocal  (C.  D ),  CodeGen  (X,  C),  CodeGen  (B.  D). 

The  bound  value’s  code  is  generated  at  the  same  static  nesting  level  as  the  block  (A);  the  body  is  gen¬ 
erated  at  a  level  one  greater  (K  + 1).  The  synthesis  rule  merely  catenates  the  code  sequences  with  the 
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ENTER  and  EXIT  instructions: 


Block  (A),  BndVal  ( X ,  A),  Body  (A,  A),  *Code  (  A,  X ,  C),  *Code  (V,  A,  D),  Nonlocal  (C,  D) 

==>  Code  ( A  *  <  ENTER>  *  V  ~<  EXIT>  ,  A,  C). 

5.9  Function  Definition 

Code  is  generated  for  a  function  definition  in  very  much  the  same  way  as  for  a  block.  The  analysis 
rule  requests  code  generation  for  the  body  of  the  function  and  the  body  of  the  function  block,  but  this 
requires  the  creation  of  two  new  contexts: 

*CodeGen  (A,  C),  FunDef  ( E ),  FunName  (A,  A),  FunFormal  (.V,  E), 

FunBodv  (B  E) .  FunScope  (A\  E) ,  Binds  (.C,  —  .  A').  *Avai]  (D.  A) 

=>  Context  (D),  Nonlocal  (  C,  A),  Binds  (A  A,  K -r  1>  ),  CodeGen  (X,  D ), 

Context  (A),  Nonlocal  ( D .  A),  Binds  (A,  A\  A'+2),  CodeGen  (A,  A) 

The  context  D  represents  the  context  of  the  function  definition  block,  which  binds  F  to  static  nesting 
level  A'  -1  (i.e.,  one  more  than  that  of  the  surrounding  context).  Code  for  the  body  A'  of  the  function 
definition  block  is  generated  in  this  context  D.  The  context  A  represents  the  context  of  the  function  s 
body,  which  binds  the  formal  A  to  its  static  nesting  level  (A  ^2,  i.e.,  one  more  than  A’ s) .  A  is  the 

context  in  which  code  is  generated  for  the  function  s  body;  notice  that  the  nonlocal  environment  of  A 

includes  A,  thus  permitting  recursive  function  invocations. 

The  synthesis  rule  gathers  the  code  generated  for  the  function  and  block  bodies,  and  assembles  it 
into  the  complete  code  sequence: 

FunDef  (A).  FunBodv  (A,  A),  FunScope  (X.  A),  Nonlocal  (A.  D). 

*Code  (A,  A,  A),  *Code  (  U,  A,  A),  *Avail  (u/,  4>) 

=?>  Code  ( 

<  JMP  [w],  LBL  \<t>\>  *  U  * 

<  RETURN,  LBL  [u/]f 
LDC  [*j,  ENTER>  *  V  m 

<  EXIT>  ,  A,  C). 
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The  label  <{>  is  the  function’s  entry  point  (which  is  left  on  the  stack);  the  label  u>  is  for  skipping  over  the 
function’s  body,  so  it  will  not  be  executed  until  it  is  called. 

6.  Function  Invocation 

For  function  invocations  the  analysis  rule  requests  code  generation  for  the  actual  parameter,  and 
lookup  for  the  function’s  name. 

*CodeGen  ( E ,  C) ,  Call  (£),  Rator  (F,  E ),  Rand  (A,  E ),  Var  (F),  Ident  (A7,  F) 

=?>  Access  (AT,  C,  F,  C),  CodeGen  (A",  C). 

Note  that  the  code  generator  requires  the  Rator  to  be  a  variable,  and  also  interprets  that  variable  as  the 
function’s  name  (as  opposed  to  a  variable  pointing  to  the  function,  etc.). 

The  synthesis  rules  picks  up  from  Location  the  static  nesting  level  at  which  the  function  was 
defined,  and  uses  it  to  assemble  the  code  sequence: 

Call  (£),  Rator  (F,  £),  Rand  ( X ,  £),  ^Location  (L,  F,  C),  *Code  (  V,  A,  C),  Binds  (C,  -,  K) 

^  Code  (  V  *  <  SKIP  [ K-L],  LOD,  SKIP  K-L+ 1),  CALL>  .  E,  C). 

The  first  SKIP  accesses  the  context  in  which  the  function  was  defined,  since  the  local  value  of  this  con¬ 
text  is  the  entry  point  address  of  the  function:  see  5.9  Function  Definition  above.  The  LOD  moves  the 
entry  point  address  to  the  top  of  the  stack.  The  second  SKIP  goes  one  further  than  the  previous,  which 
accesses  the  environment  of  definition  of  the  function.  The  actual  parameter,  entry  point  address  and 
environment  of  definition  are  left  on  the  stack  for  the  CALL  macroinstruction  (see  4.6,  Function  Invo¬ 
cation)  . 
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APPENDIX  A:  Prototype  Programming  Environment 


The  following  is  a  loadable  input  file  for  the  code  generator  described  in  this  report..  Its  operation 
requires  the  PI-4  system  listed  in  Part  IV  [ MacLennan86b ],  which  is  not  reproduced  here.  The  com¬ 
plete  system  is  accepted  by  the  McArthur  interpreter  j  McArthur84] ,  which  differs  in  a  few  details  from 
the  f2  notation  used  in  this  report  (see  [MacLennan84] ) .  A  transcript  of  a  test  execution  of  this 
environment  is  shown  in  Appendix  B. 

t 


!  CODE  GENERATOR 

i 

! 

!  Reducing  Append  Function 

fn  ap  LLj : 
if  LL=  Nil  ->  [j 

else  append  first  LL] ,  ap  rest  [ LL ]  ]  ; 

!  Relations 

newrelation  {'CodeGen"}; 
newrelation  {’Code'’}; 
newrelation  {"Access"}; 
newrelation  {’Location"}; 
newrelation  {"OpCode"}; 
newrelation  {"Create  Con  Ex  Code"} 
newrelation  {’Create  Block  Code"}; 
newrelation  {’Cre  ate  Fun  Def  Code"}; 
newrelation  {'Create FunDef2Code’’}; 
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newrelation  {"newlab"}- 
newrelation  {"LastLabel"} 


!  Machine  Op  Codes 

!  Alias  procedure  to  define  niladic  opcodes: 
newrelation  {"alias") 

act  {<  <  if  ’alias  (A,  s)  ->  define  {root,  s,  s),  A  (s);  >  >  }. 

alias  {"LOD"}; 
alias  {"ENTER"}: 
alias  {’'EXIT"}; 
alias  {"CALL"}; 
alias  {"RETURN"}; 
alias  {"BREAK"}; 

!  Monadic  opcodes: 

fn  LDC  k  :  "LDC  "  +  k: 

fn  JMP  1.  "JMP  "  -  1; 

fn  JMPT  ;1|:  "JMPT  "  +  1; 

fn  LBL  1  "LBL  "  -  1: 

fn  SKIP  delta  :  'SKIP  "  +  int_str  delta  , 

fn  PUSH  r  :  "PUSH  "  *  r: 

fn  POP  lr  "POP"  +  r: 

!  Opcodes  used  in  operator  applications: 

OpCode  ("ADD",  "+  "), 

OpCode  ('SUB", 

OpCode  ("MUL",  "x"), 


-19- 


OpCode  ("DIV", 
OpCode  ("EQL",  "=  "), 
OpCode  ("GTR",  ">  "). 


!  CODE  GENERATOR  RULES 


define  {root,  ’’CodeGenRules",  <  < 

!  Incomplete  Programs 

if  *CodeG en  ( E,  C),  Undef  (E) 

->  Code  (|  BREAK],  E,  C); 

!  Constants 

if  "CodeG  en  (E.  C),  Con  (E),  Litval  (V,  E) 

->  Code  (  LDC  int _str  V]jj,  E,  C); 

!  Applications:  Analysis 

if  "CodeGen  (E.  C),  Appl  (E),  Left  (X,  E) ,  Right  (Y,  E) 

->  CodeGen  (X,  C),  CodeGen  (Y,  C); 

1  Applications:  Synthesis 

if  Appl  (E),  Op  (N,  E),  Left  (X,  E),  Right  (Y,  E),  "Code  (U,  X,  C),  "Code  (V,  Y.  C),  OpCode  (F,  N) 
->  Code  (ap  jiU,  V,  [  F]  ]  ] ,  E,  C); 

1  Conditionals:  Analysis 

if  "CodeGen  (E.  C) .  ConEx  (E).  Cond  (B,  E) ,  Conseq  (T,  E) .  Alt  (F,  E) 

->  CodeGen  (B,  C),  CodeGen  (T,  C),  CodeGen  (F,  C); 

!  Conditionals:  Synthesis 

if  ConEx  (E),  Cond  (B,  E),  Conseq  (T,  E),  Alt  (F,  E), 

"Code  (L\  B,  C),  *Code  (V,  T,  C),  *Code  (W,  F,  C) 

->  CreateConExCode  (U,  V,  W,  E,  C,  newlab  {}  newlab  {}); 
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if  *CreateConExCode  (U,  V,  W,  E,  C,  tau,  omega) 

->  Code  (ap  [[ 

U, 

[  JMPT  ( tau]  ] , 

W, 

JMP  omega],  LBL  [tau]], 

V, 

|LBL  [omega]])],  E,  C) ; 

!  Name  Lookup  Rules 

if  *Access  (N,  D,  E,  C) ,  Binds  (D,  N,  L) 

->  Location  (L  E  C) 

else  if  *Access  (N  D,  E,  C),  Nonlocal  (Dprime,  D) 

->  Access  (N,  Dprime,  E,  C) 

else  if  *Access  (N,  D,  E,  C) 

->  Break  (,TUndefined  M  4-  N.  E,  C); 

!  Variables:  Analysis 

if  *CodeGen  (E,  C),  Var  (E),  Ident  (N,  E) 

->  Access  (N,  C,  E,  C); 

!  Variables:  Synthesis 

if  Var  (E),  ^Location  (L,  E,  C),  Binds  (C,  —  ,  K),  “Rator  (E,  —  ) 

->  Code  ([SKIP  [K-L],  LOD],  E,  C); 

!  Blocks:  Analysis 

if  *CodeGen  (E,  C) ,  Block  (E),  BndVar  (N,  E),  BndVal  (X,  E) ,  Body  (B.  E),  Binds  (C,  -  .  K) 
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->  Create  Block  Code  (C,  N,  K,  X,  B,  newobj  {}); 


if  *CreateBlockCode  (C,  N,  K,  X,  B,  D) 

->  Context  (D),  Binds  (D,  N,  K+  1),  Nonlocal  (C,  D),  CodeGen  (X,  C),  CodeGen  (B,  D); 

!  Blocks:  Synthesis 

if  Block  (E),  BndVal  (X,  E).  Body  (B,  E) ,  *Code  (U,  X,  C),  ’’'Code  (V,  B,  D) ,  Nonlocal  (C,  D) 

->  Code  (ap  [IU,  [ENTER  ,  V,  [EXIT]]],  E,  C); 

!  Function  Definition:  Analysis 

if  "CodeGen  (E,  C),  FunDef  (E),  FunName  (F,  E),  FunFormal  (N  E) ,  FunBod)  ( B,  E),  FunScope  (X, 
Binds  (C,  —  ,  K) 

->  CreateFunDefCode  (C,  F,  K,  X.  N,  B,  E,  newobj  {},  newobj  {}.  newlab  {}); 
if  *Cre  ate  FunDef  Code  (C,  F,  K,  X,  N,  B  E,  A,  D  phi) 

->  Context  (D),  Nonlocal  (C,  D),  Binds  (D,  F,  K+  1),  CodeGen  (X,  D),  Context  (A),  Nonlocal  (D.  A). 
Binds  (A,  N,  K+  2) ,  CodeGen  (B,  A); 

!  Function  Definition:  Synthesis 

if  FunDef  (E),  FunBody  (13,  E),  FunScope  (X,  E),  *Code  (U,  B,  A),  *Code  (V,  X,  D),  Nonlocal  (C,  D) 
->  CreateFunDef2Code  (newlab  {},  newlab  {},  U,  V,  E,  C); 

if  *CreateFunDef2Code  (omega,  phi,  U,  V,  E,  C) 

->  Code  (  ap  [  [ 

JMP  [omegaj,  LBL  [phi]],  U, 

(RETURN  LBL  [omegaj, 

LDC  phi],  ENTER  ,  V, 

EXIT  ]],  E,  C): 

!  Function  Invocation:  Analysis 
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if  ‘CodeGen  (E,  C) ,  Call  (E),  Rator  (F,  E),  Rand  (X,  E),  Var  (F),  Ident  (N,  F) 

->  Access  (N,  C,  F,  C),  CodeGen  (X,  C); 

!  Function  Invocation:  Synthesis 

if  Call  (E),  Rator  (F,  E) ,  Rand  (X,  E),  ‘Location  (L,  F,  C),  ‘Code  (V,  X,  C)  Binds  (C,  -  ,  K) 
->  Code  (ap  ((V,  | SKIP  |K-L],  LOD,  SKIP  [K-L  +  lj,  CALL]] j,  E,  C); 

!  New  Label  Generator 

if  ‘newlab  (A),  ‘LastLabel  (n) 

->  A  ( ,TL 11  -I-  int  str  [n  ),  LastLabel  (n  ■+•  1); 

>>}■ 

act  {CodeGenRules}. 
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!  Code  Generator  Commands 


newrelation  {"CodeGenPendin  g"}. 
define  {root,  "CodeGenComRules",  <  < 

1  codegen  Command 

if  ^Command  ("codegen"),  CurrentNode  (E),  CurrentContext  (C) 

->  CodeGen  (E,  C),  CodeGenPending  (E),  CommandPending  (E); 

if  Code  (V  E.  C).  *CodeGenPending  (E),  *CommandPending  (—  ) 

->  displayn  {’Code  generation  completed."}; 

!  showcode  Command 

if  ‘Command  (Tho wcode") ,  CurrentNode  ( E) ,  Code  (V,  E,  C) 

->  displayii  {V}; 

if  ‘Command  ( Thowcode") ,  CurrentNode  ( E) ,  "Code  (V,  E,  C) 

->  displayn  {"No  code  available"}; 

>>}• 

act  {CodeGenComRules }. 

define  {root  ’CodeGenTests",  <  < 

if  “Test  (A,  10)  ->  {  Script  { 

,rbegin",  "let",  frK",  4,  Text",  Tunc",  Tac",  T". 

"if",  "=  ",  fVar",  "n",  Text",  «#",  0,  "out",  Text",  ,l#",  1,  Text" 

"x".  "var",  T",  f Viext",  "call",  'Var",  Tac",  "next", 

’Var",  'Vi",  Text",  1,  Toot".  "in",  Text",  "in".  Text". 

"call",  'Var",  Tac"  Text",  ?Var",  "K",  "root",  "codegen",  Tho wcode" 

!}; 
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A  ('Test  done"); 

}; 


>>}• 

act  {CodeGenTests}. 

LastLabel  (0) ; 

if  *CurrentContext  (—  )  ->  CurrentContext  (newobj  {}). 
if  CurrentContext  (C)  ->  Binds  (C,  0). 

displayn  {"Pl-5  System  Loaded."}. 
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APPENDIX  B:  Transcript  of  H  Session 


The  following  is  a  transcript  of  an  fl  session  illustrating  the  operation  of  the  prototype  programming 
environment  shown  in  Appendix  A.  The  assertion  ‘Script  {testscript}’  causes  the  commands  in 
testscript  to  be  executed  in  order.  The  nth  testscript  is  executed  by  ‘Test{n}\  Each  command  is 
printed  on  a  separate  line,  followed  by  whatever  output  is  generated  by  the  programming  environment 
This  transcript  was  produced  by  the  McArthur  interpreter  McArthur84  . 

%  omega 

OMEGA-1  11/30/84 

Use  Cntl-D  or  exit{}  to  quit 

For  help,  enter  help{,r?n}. 

To  report  a  bug,  enter  Bugs{}. 
newrelation  rule  activated. 

>  do{"Pl4.rul"}.  do {Tl5.ru  1"}. 

PI-4  System  loaded 

OK 

>  PI-5  System  Loaded. 

OK 

>  Test{l0}. 

...  begin 

...  K  let 

<  expr> 

...  4  # 

...  next 

<  expr> 

.  fac  n  func 
..  if 
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<  expr> 


<  expr> 

...  n  var 

...  next 

<  expr> 

...  0  # 

...  out 

(n  =  0) 

...  next 

<  expr> 

.  i  # 

...  next 

<  expr> 

...  x 

<  expr> 

n  var 

.  next 

<  expr> 

...  call 

...  fac  var 

.  next 

<  expr> 

<  expr> 

...  n  var 

...  next 

<  expr> 
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. .  root 


let  K  =  4 

,  func  fac  n  = 

(if  (n  =  0) 
then  1 

else  ( n  x  fac  ( n  -  1) )  ) 

<  expr> 

..  in 
4 

..  next 

func  fac  n  = 

(if  (n  =  0) 
then  1 

else  ( n  x  fac  (n  -  1) )  ) 

<  expr> 

...  in 

(if  (n  =  0) 
the  n  1 

else  (n  x  fac  (n  -  1) )  ) 

.  next 
<  expr> 

.  call 
...  fac  var 


...  next 


<  expr> 


...  K  var 
...  root 

(let  K  =  4 

func  fac  n  = 

(if  (n  =  0) 
then  1 

else  ( n  x  fac  ( n  -  1) )  ) 


fac  K  j  j 

...  codegen 

Code  generation  completed. 

...  showcode 

LDC  4,  ENTER,  JMP  L3  LBL  L4,  SKIP  0,  LOD,  LDC  0,  EQL,  JMPT  Ll,  SKIP  0,  LOD, 
SKIP  0,  LOD,  LDC  1,  SUB.  SKIP  1,  LOD,  SKIP  2,  CALL.  MUL.  JMP  L2,  LBL  Ll,  LDC  1, 
LBL  L2.  RETURN,  LBL  L3,  LDC  L4,  ENTER,  SKIP  1,  LOD.  SKIP  0,  LOD,  SKIP  1,  CALL, 
EXIT.  EXIT 
>  exit{}. 


Goodbye. 

% 
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